Ein Plädoyer für Domänenwissen

Domain-Driven Design (DDD) ist eine Methodik in der Softwareentwicklung, bei der die Geschäftsabläufe, die durch die Software abgebildet werden sollen, in den Mittelpunkt gesetzt werden. Auf der DDD Europe 2017 hat Prof. Dave West über die Vergangenheit und Gegenwart des DDD gesprochen. In seinem Vortrag deckt er ein Dilemma auf, welches 1968 begann und bis heute anhält: Software Engineering.

Das Dilemma Software Engineering

Dave Wests Vortrag beginnt im Jahr 1968, als er seine ersten Programmiererfahrungen machte, und gleichzeitig das Jahr, in dem der Begriff Software Engineering geprägt wurde. Bis zu diesem Zeitpunkt war es laut West üblich, dass Software in Unternehmen selbst entwickelt wurde. In der Regel seien Mitarbeiter mit langjähriger Berufserfahrung, meist in höheren Positionen, zu Programmierern weitergebildet worden. Diese Mitarbeiter hatten natürlich ausgezeichnete Kenntnisse ihres Geschäftsfeldes, DDD war sozusagen der Standard.

In den Jahren 1968 und '69 fanden zwei durch die NATO organisierte Konferenzen statt, die von vielen als die Begründung des heutigen Berufsfelds Software Engineering gesehen werden. Software Engineering wurde eine fachspezifische Ausbildung und ist bis heute der Einstiegspunkt für eine Karriere als Softwareentwickler. Anders als in der Zeit bis 1968 ist es heute kaum üblich, dass Mitarbeiter aus anderen Bereichen zu Softwareentwicklern weitergebildet werden, um danach im selben Unternehmen zu bleiben. Mit anderen Worten: Softwareentwickler von heute haben meist keinerlei Vorkenntnisse von den Zielen und Prozessen ihrer Kunden.

Um es Informatikern trotz mangelnder Kenntnis der Geschäftsabläufe zu ermöglichen, Software zu entwickeln, die genau diese Abläufe optimieren soll, wurde die Anforderungsanalyse als eine Methode des Software Engineerings entwickelt. Diese beschäftigt sich mit dem Ermitteln und Dokumentieren der Anforderungen an ein Softwaresystem. In der Regel werden Anforderungen durch Befragen der Personen erarbeitet, die später mit der Software arbeiten sollen. Dabei werden häufig genug Mitarbeiter nach ihren konkreten Wünschen an das zu entwickelnde System befragt. Softwareentwickler erwarten also von ihren Kunden, die abzubildenden Prozesse bis ins Detail zu kennen und an einen Laien erklären zu können.

Aus dieser Erwartungshaltung, der Kunde müsse imstande sein, seine Wünsche an das zu entwickelnde System perfekt zu kommunizieren, können oft Konflikte entstehen. Möglicherweise erwachsen daraus Systeme, die nicht alle Anforderungen erfüllen oder den Fokus auf die falschen Details legen. Da die Anforderungen im Vorfeld meist schriftlich festgehalten werden und als Vertragsgrundlage dienen, neigen einige Softwareentwickler dazu, ihren Kunden nachher sogar die Schuld dafür zuzuweisen.

Als Hauptprobleme der Anforderungsanalyse werden unter anderem unklare Zielvorstellungen und Sprachbarrieren genannt (Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil, Seite 13). Genau hier invertiert DDD die Rollenverteilung: DDD setzt voraus, dass der Softwareentwickler das Geschäftsfeld des Kunden so gut kennt, dass er die Anforderungen an die zu entwickelnde Software nahezu selbst erarbeiten kann.

Domain-Driven Design als Lösungsansatz

Die wohl wichtigste Komponente des DDD ist die “Ubiquitous Language”, eine einheitliche, festgelegte Sprache, in der die für den Geschäftsbereich wichtigen Begriffe erklärt und definiert werden. Anstatt den Kunden zu zwingen, sich mit Softwareentwicklung zu beschäftigen, zwingt DDD den Entwickler, das Geschäftsfeld des Kunden zu erlernen.

Wenn Entwickler das Geschäftsfeld ihrer Kunden verstehen, dann können sie besser beurteilen, welche Prozesse mit welchen Prioritäten automatisiert werden sollten. Dadurch soll die daraus entstehende Software schlanker und effizienter sein. Eric Evans argumentiert, dass durch den Ansatz des DDD das Erschaffen sogenannter tiefer Modelle (Deep Models) möglich wird. Solche tiefen Modelle bilden die Geschäftsprozesse so genau nach, dass die entstehende Software um ein vielfaches effizienter und einfacher erweiterbar sein soll. Anders gesagt: mit genug Vorwissen über ein Geschäftsfeld sollten wir in der Lage sein, perfekte Anwendungen zu entwickeln und dabei noch die Geschäftsprozesse zu optimieren.

Häufig tendieren Softwareentwickler dazu, in neuen (oder wiederentdeckten) Methoden die Lösung aller Probleme zu sehen. Deshalb gibt West zum Ende seines Vortrags mit einem Augenzwinkern noch als kleine Warnung (oder Motivation) ein Zitat von Vitruvius mit:

“The ideal architect should be a man of letters, a skillful draftsman, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.”

Zusammengefasst: Ein idealer Architekt sollte fundierte Grundlagen aller Künste und Wissenschaften mitbringen. Im übertragenen Sinne bedeutet das: Das Versprechen von perfekter Software setzt auch perfektes Wissen voraus. Wie so oft gilt es wohl, nach einem Mittelweg zu streben.

Erfolg ist eine Frage der Einstellung

Dave West hat mich mit seinem Vortrag überzeugt, dass der wichtigste Bestandteil der DDD-Bewegung die Erkenntnis ist, dass die erfolgreiche Entwicklung von Software ein gutes Verständnis des Geschäftsfeldes voraussetzt. Zwar ist klar, dass nicht jeder, der ein CRM-System entwickeln möchte, zuerst über mehrere Jahre im Vertrieb gearbeitet haben muss. Dennoch muss es Voraussetzung sein, zu Beginn eines Projektes Gespräche zu führen und sich auf anderem Wege die nötigen Informationen zu beschaffen, damit man sich ausreichend gut in die Lage des Benutzers eines CRM-Systems versetzen kann.

Wir als Softwareentwickler sind dafür verantwortlich, Applikationen zu entwickeln, welche unseren Kunden weiterhelfen. Wenn die Anforderungen an ein System falsch dokumentiert werden, sollte der Fehler zuerst bei dem fehlenden Verständnis des Entwicklers für das entsprechende Geschäftsfeld gesucht werden, anstatt beim fehlenden Verständnis des Kunden für Softwareentwicklung. Wir für unseren Teil versuchen, dies in allen unseren Projekten zu beherzigen und haben uns in den vergangenen Jahren dadurch eine ganze Menge Domänenwissen angeeignet.

Verweise

• Zusammenfassung des Vortrags von Dave West auf der DDD Europe 2017
• Persönliche Webseite von Dave West
• Wikipedia-Eintrag zur Geschichte des Software Engineerings